Many existing portable devices, such as cellular telephones, include one or more diagnostic applications (which may be in the form of software, firmware, and/or the like) operable to gather diagnostic information regarding the operation of the device. Such information may be helpful in diagnosing, and perhaps correcting, the cause of one or more abnormalities occurring in the operation of the device.
These abnormalities can occur in various hardware systems or in software applications within the device. In the present environment, in order to retrieve such diagnostic information from a cellular telephone, an “AT” command (similar to the command sets used to control modems) is sent to the serial port of the telephone from an external source. Typically, such command sets are sent by a test application executing on an external controller (such as a personal computer) attached to the serial port of the cellular telephone via a serial cable. In response to the receipt of the aforementioned command sets, the cellular telephone performs internal testing and transmits the diagnostic information to the external controller via the serial cable. The external controller, in turn, analyzes the information to determine if there are problems with the cellular telephone.
One drawback with the above-discussed approach is that it requires an additional piece of equipment, namely the external controller, to initiate the request for data and to then retrieve the diagnostic information from the cellular telephone. This additional piece of diagnostic equipment is one that users of cellular telephones typically do not own or have access to. Therefore, in order to retrieve the aforementioned diagnostic information, the cellular telephone must be carried (or sent) back to the manufacturer, and/or service provider, to be diagnosed. Even if the user of the cellular telephone owned such a controller, there is considerable complexity in configuring a general purpose computer for such tasks. Thus, the existing approaches are suitable only for a centralized professional testing system.
The typical serial port hardware driver is a piece of software which communicates with the actual hardware. Typically, hardware is visible to software by being mapped to some memory addresses (this is typically called memory mapped I/O). For example, a certain hardware signal may be mapped to memory address 0x800000. There is actually no memory at 0×800000. When the software writes a 1 to 0x800000, the hardware signal gets set to high. And when the software writes a 0, the line gets set to low. This is how software interacts with hardware.
Typically, the software that performs these functions, called the hardware driver, is separated in a separate module from the rest of the software. For instance, there may be a software function called set_trigger( ) which actually writes to location 0x800000 as in the above example. The rest of the software system only knows to call set_triggers( ), not to write to 0x800000. This is so the software system is not impacted if the hardware designer remaps the line somewhere else in memory.
The serial port device driver has knowledge of how to carry out serial communication protocol functions. It is capable of performing handshaking and sets the signals according to some predefined transitions so both sides of the communication link can exchange data. The device driver talks to the hardware through a hardware driver described above. That is, it does not write to an memory addresses, but rather does so through the hardware driver. The device driver can be said to encompass the hardware driver.